1. Field of the Invention
The present invention relates to a decision management system for creating strategies to manage customers of an organization. More specifically, the present invention relates to a decision management system to simultaneously evaluate customer and account data.
2. Description of the Related Art
A typical organization maintains a significant amount of information about its customers to support the services of the organization. This information can be effectively used, for example, to increase productivity and reduce costs, while achieving the goals of the organization. Such goals may be to improve profitability and maximize customer value.
For example, a company may sell various products to its customers, and may maintain a significant amount of information relating to its customers. This information can be used to improve many critical interactions with the customers, such as marketing communications, sales calls, customer service, collections, and general relationship management activities.
Consider the following examples.
Assume that a diversified financial services company is trying to leverage its customer base by cross-selling its various products. It currently uses limited internal customer information and credit bureau information to identify existing customers for cross-sell campaigns. For example, they might send “invitations to apply” for a home equity loan to those customers who own a mortgage with the company, and meet a minimum credit bureau score threshold. Imagine how much more powerful their cross-selling efforts would be if they could use information from all of the customers' accounts to offer pre-approved home equity loans to customers where the likelihood of a sale was high, the probability of default was low, and the financial value of that sale was high.
As another example, assume that a regional bell operating company is currently applying only age-based criteria (e.g., “days past due”) to its accounts receivable portfolio to identify candidates for its collections department and to handle those customers. The content of the outbound collection notices and phone calls is driven solely by the age and amount of a customer's unpaid balance. Imagine if the company had a tool that helped it select and prioritize collection accounts based on the likelihood of a customer interaction making a bottom line difference. Instead of calling or writing all overdue accounts, they could focus resources on those where the customer interaction would make the greatest difference. In addition, they would save the expense and ill will generated by calling customers who would pay without a collections contact.
As a still further example, assume that a manager of a large telephone customer service center for a super-regional bank has been given only hard-line corporate policy to make decisions about fee and rate concessions. While her service reps attempt to stay to the company line, she is deluged with requests from good customers to talk to the manager. She uses her judgment based on the incomplete information available to her to decide which concessions are appropriate to prevent attrition of profitable customers. Just imagine if the service reps had guidelines that were specific to each customer, based upon customer data that indicates their value to the organization, likelihood of attrition, risk level, and other characteristics. The manager could stand by these guidelines with confidence. There would be no concessions made to unprofitable customers, fewer manager overrides, shorter calls, and reduced attrition of the customers they want to keep.
As diverse as the above examples appear on the surface, they share several common characteristics. Each involves a large customer base and a high volume of customer interactions. Each organization has a substantial amount of accumulated data regarding the characteristics, purchasing/behavior patterns, and profitability of customers (though the data may not yet be well organized or analyzed). Each organization has an opportunity to improve performance substantially by treating different customers and customer groups differently, due to diversity in customer relationships and their potential. In each case, there are desired outcomes that could result from alternative customer interactions (e.g., customer purchases a product, pays an outstanding bill, increases deposit balances), and those outcomes can readily be identified, quantified, and tracked.
In sum, each of the above examples depicts a business situation that currently is not fully benefiting from decision support and therefore is yielding less than optimal results.
There are software based products in the marketplace which can organize information to make more effective decisions. For example, the American Management Systems (AMS) Strata™ decision support system release 2.0 (hereinafter Strata™ release 2.0) is a software based system which applies predictive modeling techniques to customer data, to thereby generate dramatic improvements in the effectiveness and profitability of customer interactions.
FIG. 1 is a diagram illustrating the general concept of a software-based decision management system, such as Strata™ release 2.0, which applies predictive modeling techniques to customer data.
Referring now to FIG. 1, a software based system 10 receives information from operational and/or customer information systems 20, such as, for example, billing systems, account management systems, credit bureau systems and data warehouses. Software based system 10 prioritizes and tailors customer interactions based on predictive information, specific business rules, and continually evolving decision strategies. Software based system 10 then determines an appropriate action which is to be taken by an action-taking system 30. An appropriate action to be taken could include, for example, a call to a customer, a specific collections procedure or a specific marketing action.
A decision management system as in FIG. 1 can provide superior results, such as increased revenue generation, improved cost-effectiveness and enhanced customer relationships.
FIG. 2 is a more detailed diagram illustrating the operation of the decision management system Strata™ release 2.0.
Referring now to FIG. 2, in step 40, an inbound event is a trigger that is received from one or more external systems to identify that a particular customer event has occurred. Such events may be automatically generated due to customer behavior or systematically produced at specified time intervals (i.e., monthly). Examples of inbound events include a customer declaring bankruptcy, a credit underwriting decision request, a credit account delinquency, an income statement cycle date, or a routine evaluation date (a periodic, scheduled evaluation).
From step 40, the system moves to step 50, where a customer is assigned to a segment. A segment is a grouping of customers based on a characteristic by which the customers will be separated for applying different rules. Generally, a segment is a high level segregation of customers for the purpose of associating largely independent high level strategy. Segments are completely separate groups of customers, for which a unique set of evaluation processes have been defined. For example, a telecommunications company might have a segment for residential customers and another for business customers.
From step 50, the system moves to step 60, where customers are randomly grouped into different test groups for the purpose of applying competing policy rules, strategy, or experiments. Generally, test groups allow for strategy comparison. Just as in research environments, the behavior or outcomes of an experimental “test” population is compared to that of a “control” group that is not exposed to the experimental treatment. A strategist can specify what percentage of the customers should be randomly assigned to each test group. If the strategy associated with a test group is successful, that strategy may later be deployed to a larger percentage of the customers.
From step 60, the system moves to step 70, where inbound events are matched to processes. More specifically, it is defined which processes are invoked in response to each inbound event. For example, different processes are created for a credit card campaign versus a late payment. The order of process execution is also specified.
Processes can be seen as individual decision logic modules which are invoked in response to inbound events. This modular approach to defining decision strategies facilitates logic re-use and the ability to deploy robust strategies required to coordinate customer, account and marketing decisions.
From step 70, the system moves to step 80, where the specific processes for specific inbound events coming into the system are executed.
From step 80, the system moves to step 90, where the results, or action to be taken, are output.
Therefore, in FIG. 2, based on the type of inbound event(s) received, an appropriate sequence of decision logic modules, or processes, is invoked, where the sequence of decision logic modules is predefined by a strategy analyst.
FIG. 3 is a diagram illustrating an example of a segment being divided into different test groups as in step 60 of FIG. 2. Referring now to FIG. 3, 10% of the segment is randomly assigned to test group 1, 10% of the segment is randomly assigned to test group 2, and 80% of the segment is randomly assigned to test group 3.
FIGS. 4(A) and 4(B) are diagrams illustrating the matching of inbound events to processes in step 70 of FIG. 2. Referring now to FIG. 4(A), for example, when an inbound event 91 is a credit card campaign, the following processes are applied, in order: credit card propensity to buy score 92, risk score 93 and offer selection 94. A result 95 of the applied processes is a determination of whether to send a credit card offer.
Similarly, referring now to FIG. 4(B), for example, when an inbound event 96 is a late payment, the following processes are applied, in order: risk score 97, underwriting treatment 98 and overdraft decision treatment 99. A result 100 of the applied processes is a determination whether to send new underwriting and overdraft codes.
Processes are decision logic modules formed by one or more “mechanisms”. Mechanisms can be, for example, decision trees or score models. There are preferably several different mechanisms which are available in the creation of any process. One or more mechanisms are typically grouped into processes when they have comparable objectives (i.e., score cards to predict risk, decision trees to evaluate a credit line, etc.). Generally, the objective is typically reflected in the name of the process itself as defined by the user.
In this conventional decision management system, only a single set of variables is defined. This single set of variables is written over and used for each process. Subsequent processes write over the data stored in the variables from the previous process. For example, referring to FIG. 4, once a risk score is computed by risk score 93, this risk score is stored into a variable which may have stored a score computed by credit card propensity to buy score 92. Thus, the results of the processes are written over each other into the same set of variables. In this manner, the decision management system has a forced dependency between processes.
FIG. 5 is a diagram illustrating the grouping of mechanisms to processes. Referring now to FIG. 5, when an inbound event 91 triggers a specific process, the specific mechanism to be applied to a customer will be determined by the test group into which the customer was assigned. This allows for strategy experimentation by defining a common sequence of processes for a given inbound event, but differentiating the actual mechanism that will be invoked for each process depending on the respective test group into which the customer was randomly assigned.
If a process only contains one mechanism, no experimentation will take place in that process since every customer, regardless of its test group, will be required to use the mechanism. For example, in FIG. 5, no experimentation takes place in the credit card propensity to buy score 92, since this process contains only one mechanism. By contrast, in FIG. 5, experimentation takes place in offer selection 94, since this process includes more than one mechanism. This approach provides the strategy analyst with the flexibility to selectively experiment on each component of the overall strategy, as appropriate.
Processes can include many different types of mechanisms, including decision trees, score models and matrices. Decision trees are the most common.
FIG. 6 is a diagram illustrating a decision tree. A decision tree employs pre-defined logic to route customers to the appropriate endpoint. Generally, a decision tree contains layers of rule-driven decision points, or nodes (starting with a root node at the top of the tree), from which customers are allocated to lower and lower branches of a tree until they ultimately reach an endpoint of the tree (a terminal node). Because decision trees can vary in structure (e.g., number of branches, nodes per branch) and because decision trees can call other decision trees, decision trees provide extensive flexibility for designing customer strategies.
Unfortunately, with a conventional decision management system executing customer level policy, a separate decision tree must be designed for each account, regardless of the type of the account. Thus, the same decision tree can not be applied against multiple accounts for the same customer.
For example, FIG. 7 is a diagram illustrating a conventional decision tree for a specific credit card, referred to as credit card #1, of a customer. Referring now to FIG. 7, a conventional decision tree has specific decisions set forth for the specific credit card. For example, in step 105, the system follows a different path through the decision tree based on whether the customer a high risk or a low risk customer. If the customer is a high risk customer, the process moves to step 110, where the balance of credit card #1 is determined. If the balance is between 0-500, then decision D1 is made. If the balance is between 501-MAX, then decision D2 is made. For example, decision D1 may be to cancel the credit card account, and decision D2 may be to increase the interest rate on the credit card account.
By contrast, in step 105, if the customer is a low risk customer, the process moves to step 120, where the credit limit of credit card #1 is determined. If the credit limit is between 0-500, then decision D3 is made. If the credit limit is between 501-MAX, then decision D4 is made. For example, decision D3 may be to increase the credit limit of the credit card account, and decision D4 may be to reduce the interest rate of the credit card account.
The determination of whether each customer is a high risk or a low risk customer is made before step 105 is executed, and the results of the determinations are stored in the system memory. Therefore, step 105 does not make the determination of whether the customer is a high risk or low risk customer, but simply retrieves the previously made determination from the system memory.
While the decision tree in FIG. 7 may be effective in designing a strategy for credit card #1, such an approach requires a separate decision tree to be created for each account, regardless of the type of account, when processing at the customer level. For example, if a customer has three credit card accounts, then a separate decision tree must be created for each credit card account. As a result, three separate decision trees must be created, each referencing the data of a specific account. Similarly, for example, if the customer has two or more mortgages account, then a separate decision tree must be created for each respective mortgage account.
As can be seen from above, a conventional decision management system will require a different decision tree for each of a customer's accounts. Thus, the decision management system must get data for a specific account, and then perform an evaluation for that account. The decision management system must then get data for the next account, and then perform an evaluation for that account. This repeating operation of retrieving data and performing evaluations is referred to as a “multi-pass” operation. Such a multi-pass operation greatly increases the complexity and reduces the efficiency of the system, especially when customers tend to have many accounts of the same type.
Similarly, since a conventional decision management system does not have the ability to define a mechanism without referencing a specific account (versus a type of account), maintenance of the strategy will be substantially increased. Simultaneous customer and account evaluation would not be feasible if each customer could have a different number of accounts.